Failures are relevant: sqlite and postgres create different db objects based on the column specification index=True unique=True, which is why our migration tests fail. One more cross-database gotcha..

Implementation note on indexes and unique constraints
In both postgresql and sqlite, a unique constraint is implemented as an index. When the model's column definition contains both index=True and unique=True, only one index will be created. Therefore, attempting to create or drop both the index and the unique constraint in the migration script will result in an error. To handle this, we simply use create_index, passing unique=True as a keyword argument.

If we are adding a unique constraint to a column that had an index defined on it, we must drop that index, because it did not enforce a unique constraint. However, only existing databases will contain that index, new databases will not - so we must check for its existence in the migration script before issuing the drop_index command.

unit test failures relevant: the tests don't respect the new constraints. I'll fix this.
UPDATE: fixed.

So this has a new kind of test: individual migration test. The purpose is to test how existing data (that would prevent the execution of a particular migration) is fixed in the database during the migration process. For example, let's say we are adding a unique constraint to a field that currently contains duplicate values. We must cleanup the data before we can run this migration, so we have a script that handles this cleanup (by deleting duplicates, or deduplicating them, etc.). This test verifies such a script.

Here's what the test does:

1. Load and initialize a new database and migration environment
2. Downgrade to the revision BEFORE the migration under test
3. Load and verify bad data (that would have prevented running the next revision script)
4. Run the migration (via alembic)
5. Verify that data has been cleaned up as expected.

Integration test failures unrelated.